need to cd to USERDIR as well here?

and if we do, several of the $USERDIRs below can/must be eliminated

could add creating some hpc-wide environmental variables to the longleaf-setup repo. does that make sense to pair with this?

lastly ... bit weird that we're doing install here in scratch. why not in $HOME? i get doing projects on scratch.

per in-person conversation:

• need to check the preferred location for libraries on longleaf & rockfish
• maybe refer to that as $LIBDIR (or ACCLIBDIR or some such)
• might want to move that as a generic variable to be set on the HPC, and if so - move that to the longleaf-setup directions (which could itself stand to be scriptified) and make that setup a prerequisite to this? (one downside to that would be other people on other HPCs wanting to use / modify this script - future problem?)

At least on the longleaf side it looks like /users is similar to $HOME, the documentation states "Think of it as a capacity expansion to your home directory." However, I think maybe the project directory should be moved to /work since that's high throughput and designed for active jobs. So my take is:

• flepiMoP and flepimop-env stay in /users, especially for the conda env since that directory can get large and $HOME has some low and strict storage caps.
• Move the project directory to /work since that'll actually need throughput for the job.

I still need to dig up the rockfish documentation. Longleaf docs: https://help.rc.unc.edu/getting-started-on-longleaf/#main-directory-spaces.

Thanks for these scripts - the install all worked great for me on longleaf. 🎉

I'm also open to having these things anywhere, but as @jcblemai said I think having everything (including the flepimop libraries) in /work or /scratch makes the most sense, including the flepiMoP folder itself. I understand how installing these in /users or /home would be ideal if flepiMoP was stable but from a practical perspective, I am operationally often changing things within flepimop and reinstalling things run-to-run, playing with my own different environments, jumping between branches, or jumping between different FLEPI_PATH 's (not ideal, but practically this is just what we've had to do with concurrent runs and changes). So for convenience it would be good to just have everything in the same place, imo.

Separately, with my experience with running stuff in the past I was confused with having to link the specific location of the flepimop-env . I'm fine either way, I just don't think I follow why the change

@saraloo is there a general class of the things you're changing?

I would put everything in /scratch/ on rockfish (as per the current doc)

This has been the case since 9ca12ed. I see, this is not the case for the $USERDIR variable, done now as well.

and in /work/ on longleaf, for both convenience and speed.

This is done now. I think I am misinterpreting the docs (see https://help.rc.unc.edu/getting-started-on-longleaf/#main-directory-spaces) on the differences between /users and /work. @jcblemai what are the practical differences between the two? My interpretation was that /work was mean for high IO short term storage for active work whereas /users is designed for longer term lower IO (read okay?) storage for libraries/codebases.

I am operationally often changing things within flepimop and reinstalling things run-to-run, playing with my own different environments, jumping between branches, or jumping between different FLEPI_PATH

@saraloo is this normal operational behavior? This sounds like the installation script needs to be much more accommodating to flexibility if this is the case. For the different environments, do you mean switching between multiple conda envs? What makes each of these envs distinct? As far as jumping branches this script won't do anything to your flepiMoP clone, although you can switch the branch yourself and then run this script again to update the conda env with the code from that branch ("install" is a misnomer, it really should be "install or update", I'll change the script name and make sure this is clear when writing the documentation), does that accommodate this use case? As for different $FLEPI_PATHs this script checks if this env var is set before doing anything, and if it is just uses the set value so there should be no issue setting custom $FLEPI_PATHs. Have you tested this yet and does it accommodate your use case?

Responding to both simultaneously. No, i don't think this is normal behavior so feel free to make a judgement call on your end. Just in the past during larger periods of development which inevitably coincide with operational demands I was running two or three different diseases on significantly different gempyor and/or R inference setups from different conda environments (again, don't think this will necessarily be standard, especially now that more people can run stuff). Just flagging that there will be circumstances where flexibility is preferable and want to reduce the possibility of someone setting the wrong flepimop version they;re working on or something, or reducing having to jump around etc to switch branches.
And sorry, haven't tested the FLEPI_PATH bit yet but that makes sense and I don't anticipate any issues there with setting that.

As we move to the new workflow carl described today, it means that we will have custom branch for runs so you can envision someone running Flu and RSV from the same account but using two different flepiMoP branch. I however think this flexibility can be added alter with the pre-runs scripts that are mentionned below.

Sometime also when running to many parallel run we can have some filesystem lock on the packages, which is always annoying, but I would not worry about it too much.

RE to sara's questions: do we need to specify the emplacement of the conda environement ?

. @jcblemai what are the practical differences between the two? My interpretation was that /work was mean for high IO short term storage for active work whereas /users is designed for longer term lower IO (read okay?) storage for libraries/codebases.

This is correct, but flepiMoP does not support writing to other folder other than the project one, so we work from work.